home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part1 / 38 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.8 KB

  1. Path: mujibur.inmind.com!usenet
  2. From: mfinney@inmind.com
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Hungarian notation
  5. Date: 2 Jan 1996 03:50:14 GMT
  6. Organization: In Mind, Inc.
  7. Message-ID: <4caa1m$1vc@mujibur.inmind.com>
  8. References: <30CBAA22.791B@erols.com> <4agus6$qqc@news1.usa.pipeline.com> <30CE4E36.5190@erols.com> <30CFD9CD.3D09@zeta.org.au> <4c3ncl$gm4@nnrp1.news.primenet.com>
  9. Reply-To: mfinney@inmind.com
  10. NNTP-Posting-Host: finneyman.inmind.com
  11. X-Newsreader: IBM NewsReader/2 v1.2
  12.  
  13. In <4c3ncl$gm4@nnrp1.news.primenet.com>, jrice@primenet.com (Jer) writes:
  14. >The above is "nice". But, when the boss walks in and says, "I want
  15. >this out now!", 'standards' go to the wind, relative to a pay check.
  16.  
  17. No.  Not if you are professional.  At worst case, you will use a
  18. personal standard if there is no other standard available.  Nor
  19. is there any such thing as a "one shot" program.  No compromises
  20. should be made when writing a program just because you are
  21. told it is a "one shot" program.  I know of far too many programs
  22. of this nature that have been shipped out the door.  If somebody
  23. tells me that something is a one shot program then I write it, run
  24. it and erase it.  Period.  And even then it is written according to
  25. a standard.
  26.  
  27. >Secondly, standards are only helpful if the "replacement" programmers
  28. >have been trained in The 'standard', otherwise they have to learn the
  29. >'standard' before proceding, which again puts them in jeopardy of the
  30. >first comment I made.
  31.  
  32. Yes, but how long does that take?  Five minutes, ten?  Surely not
  33. more than an hour!  You can afford an hour if it has to come out
  34. of your own time.  And if the company is not willing to give a new
  35. hire an hour (or a day for that matter) to "come up to speed" on
  36. issues like this, then I strongly suggest looking for another position.
  37. After all, it is not something that (normally) changes on a day to
  38. day basis!
  39.  
  40. My companies have even required short term contractors to program
  41. to the local standard.  No quarter in this area!
  42.  
  43. > Most of the managers that I have worked for
  44. >don't give a hoot about standards, all they care about is when!!
  45.  
  46. But *YOU* as a professional programmer do!  If the employer of a
  47. civil engineer felt that safety margins were not "necessary" for a
  48. bridge and the engineer omitted them, he could be sued for
  49. unprofessional behaviour.  There are simply somethings you don't
  50. compromise on.
  51.  
  52. Writing good code is one of them.
  53.  
  54. Even under time pressure.  Even if lives are depending on it.
  55. Because doing so is more likely to save those lives by *NOT*
  56. having a bug in the code than taking the time to be careful
  57. in the first place.  And even that time is almost always paid
  58. back before you are done.
  59.  
  60. Not that adherring to standards takes one second longer than
  61. writing random code.  I suppose you could argue that indentation
  62. takes longer -- but I would suggest that even there, learning to
  63. type (or to type faster) would be far more significant.  Not to
  64. mention using something besides EDLIN to enter you program!
  65. And the data entry of a program is rarely the limiting factor in
  66. writing code.  Understanding is.  And *THAT* is where adherrance
  67. to standards helps.
  68.  
  69. In other words, expediency is *NOT* justification for throwing
  70. professionalism out the window!  Have a set of personal standards
  71. which are the best you can make them which you can use if there
  72. is no overt standard or which you can use to fill in the holes of
  73. any existing standard.  If you are modifying an existing program
  74. use the style and standard that program uses.  If done properly,
  75. the original author should not be able to tell that he did not write
  76. the code after you alter it (at least without direct comparison to
  77. the original code).  If writing a new program use the standards
  78. for the company.  If there aren't any then use yours.  They may
  79. well become the default standard.  But *USE* one -- or get
  80. another profession.
  81.  
  82.  
  83. Michael Lee Finney
  84.  
  85.